In the Universal Mobile Telecommunications System (UMTS) a general protocol reference model containing a layered protocol stack is used for providing reliable communication of user data and signaling between the nodes of the network. UMTS also employs the concept of control-plane and user-plane, where the control-plane is a set of protocols used exclusively for control signaling purposes, while the user-plane is used exclusively for user data transfer.
A user-plane protocol stack in UTRAN according to the prior art is illustrated in FIG. 1. The figure illustrates the protocol stack of a User Equipment (UE) 100 communicating with a Serving Radio network Controller (SRNC) 110 and an intermediate Node B 120. The Physical layer (PHY) 101, 121 offers services to the Medium Access (MAC) layers via transport channels, while the MAC layers (MAC_e/hs/d) 102, 103, 111, 122, in turn, offers services to the Radio Link Control (RLC) layer 104, 112 by means of logical channels. MAC-d handles dedicated channels, which may be mapped to common transport channels, wherein MAC-d passes data to MAC-hs or MAC-e. MAC-hs denotes the downlink MAC entity and is used for serving the High Speed Downlink Shared Channel (HS-DSCH), introduced in Release 5 of the 3GPP specification, while MAC-e denotes a MAC entity related to the new uplink channel, Enhanced Dedicated Channel (E-DCH), introduced in Release 6.
In the user-plane, which is illustrated by the figure, the RLC layer offers services to the Packet Data Convergence Protocol (PDCP) 105, 113. A control-plane may be illustrated by simply changing the PDCP layer to a Radio Resource Control (RRC) layer.
A Service Data Unit (SDU) can be conceptualized as a data unit received from, or submitted to, a higher protocol layer, e.g. RLC. A Protocol Data Unit (PDU) is a unit which is submitted to, or received from, a protocol layer logically located beneath the protocol from which the SDU is received. The PDU comprises a mandatory header and, optionally also a Length Indicator (LI), which indicates the last octet of each higher-layer SDU, ending within the PDU. The PDU also comprises a data field, containing one or more segments from one or more higher-layer PDUs.
The RLC protocol provides radio bearers for user data transfer and signaling radio bearers for control signaling and includes functionality such as RLC segmentation, re-assembly, and potentially also concatenation of RLC SDUs into RLC PDUs. At the transmitting end, segmentation and/or concatenation is used in order to match currently used Transport Formats (TF), i.e. predetermined PDU sizes. In the receiving end the segments belonging to one higher-layer PDU are re-assembled before they are delivered to the higher-layer. An RLC SDU is typically an IP Packet or a signaling message, while an RLC PDU typically is a MAC_d SDU. If a higher-layer PDU segment does not completely fill the payload field of the RLC PDU, the first segment in the next higher-layer PDU may be put in the RLC PDU in concatenation with the last segments of the previous higher-layer PDU.
The RLC protocol includes the three different modes Transparent Mode (TM), Unacknowledged Mode (UM) and Acknowledged Mode (AM). In AM, the RLC deploys re-transmission to guarantee lossless delivery of all RLC PDUs, while no re-transmission, and, hence, no guarantee of data delivery is deployed in UM. In TM, no protocol overhead is added by the RLC layer. The present disclosure is applicable to the UM and AM modes.
Both UM and AM of RLC uses segmentation and optionally concatenation on the transmitter side, while re-assembly is used on the receiver side.
In the current UTRAN architecture, the RLC protocol is terminated in the Serving Radio Network Controller (SRNC) and in the User Equipment (UE), respectively. The present disclosure does, however, not preclude a different architecture, where the terminating point of the protocol deploying segmentation, re-assembly and concatenation is placed elsewhere, e.g. in the base station (node B). The RLC PDUs are submitted to, and received from, the Medium Access Control (MAC) protocol, which realizes the transport channels over the UMTS air-interface, the Uu interface.
In the existing UTRAN protocol stack, the RLC PDU size for a given radio bearer can only take a discrete number of different sizes, which are configurable by upper layers of the protocol stack. For RLC AM, the RLC PDU size can only take a single value. The most commonly used RLC PDU size for user-plane transmissions is 320 bits of payload and a 16 bits RLC header. It can be configured and re-configured by higher-layers, and bearers carrying signaling typically deploy a PDU size, carrying 128 bits of payload.
For RLC UM, there is a possibility to configure several RLC PCU sizes. The header fields in MAC-hs and MAC-e, however, restrict the de-facto numbers of different sizes that can be used. For example, it is currently possible to use maximally eight different MAC-d PDU sizes over HS-DSCH, where a MAC-d PDU is an RLC PDU and an optional MAC-d header.
The fact that the RLC PDU size can only take one single size, or a discrete set of sizes, means that RLC SDUs typically need to be segmented and/or concatenated into an appropriate number of RLC PDUs. One drawback with such a limitation can be extensive protocol overhead and padding. Padding occurs if concatenation cannot be used, i.e. the remaining payload to be segmented into an RLC PDU does not fill the available space of the most suitable RLC PDU size. Such a situation can be illustrated with the two following examples.
In a first example we consider the transmission of one 1500 octet IP packet. It is assumed that an RLC PDU size of 320 bits, i.e. 40 octets, is used for segmentation. This implies that the IP packet is segmented into 38 RLC PDUs, having the capacity of delivering 1520 octets.
In this case, the RLC header overhead equals 38*2 octets and a one octet length indicator, inserted in the last RLC PDU, which makes a total of 77 octets, while padding, which is used to fill up the last RLC PDU, equals 19 octets. This means that for the transmission of 1500 octets, a total RLC overhead of 96 octets will be necessary.
In a second example, the transmission of one compressed Transport Communication Protocol Acknowledgement (TCP ACK) is considered. A TCP ACK is typically 40 bytes long. In this example it is assumed that a TCP ACK is compressed down to four octets by a conventional header compression protocol. The RLC protocol adds a two octet fixed header and a one octet length indicator and adds padding up to the full RLC PDU size. With the typical RLC PDU size of 320 bits, this implies a 38 octet header overhead and padding for transmission of just four octets of payload.
The first example clearly illustrates the deficiency of using fixed RLC PDUs when segmenting and/or concatenating large RLC SDUs, while the second example shows the inefficiency which may occur when segmenting and/or concatenating small RLC SDUs.
To overcome the problems mentioned above, an RLC protocol that is able to use any RLC PDU size has been proposed in R2-052508 “User plane protocol enhancements”, presented at TSG-RAN WG2 Meeting #48bis, Cannes, France, 10-14 Oct. 2005. Such a flexible RLC solution may allow arbitrary RLC PDU sizes, such that the RLC PDU equals the size of the RLC SDU and the necessary RLC header, and may also provide a minimal level of RLC overhead. In addition, such a solution may remove the need for padding. In the first example, mentioned above, the required overhead with the solution proposed in R2-052508 “User plane protocol enhancements”, would be 2 octets, as opposed to 96 octets. In both examples, the padding would be zero octets, as opposed to 19 and 38 in the first and second example, respectively.
Still, a problem of handling large RLC SDUs, i.e. large IP packets or long signaling messages may occur also when using the solution referred to in R2-052508, especially when transmission coverage and RLC AM re-transmission efficiency is considered.
This deficiency can be illustrated in a first scenario, wherein a large SDU PDU of 1500 octets is forwarded to the MAC protocol as a single RLC PDU, without deploying any segmentation. The transmission of the RLC PDU in a single transport block in MAC-hs or in MAC-e may lead to coverage problems, i.e. a sufficiently large transport block may not be supported in the whole cell, which may result in a failure to deliver the large RLC PDU. In other words, if the link quality between a user equipment and a radio base-station is bad, the MAC protocol may fail to deliver such a large block as a single transmission unit. Trying to solve the scenario described above by adapting the transmission blocks size to the link-quality by introducing segmentation and concatenation into MAC, may not be adequate, since such a solution may result in a low RLC AM re-transmission efficiency. Considering once again the first example, described above, assuming that MAC-hs segments the IP-packet into 38 transport blocks. Hybrid Automatic Repeat Request (HARQ) is an advanced retransmission strategy, which allows the performing of possible re-transmissions directly at the physical/MAC layer. This is done without involving higher-layer mechanisms and so reduces the delay.
Due to an error in the HARQ feedback signaling or an error caused by the reaching of the maximum number of HARQ re-transmissions, all but one of the respective transmission blocks may be successfully delivered. In such a case, the whole RLC PDU of a 1500 octet and an RLC header has to be re-transmitted, resulting in a very low RLC re-transmission efficiency.
Despite the obvious performance benefits gained from using a flexible RLC according to the prior art, the scenario described above clearly illustrates that there are situations when large RLC PDUs can create problems, which typically occur at times of bad link quality, or when there are not enough of transmission resources in terms of power, spectrum or time-slots available.